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We, Dan Alan Brendes, Joseph William Keller, and Seetharaman Khadri, being 
the inventors of the subject matter of the claims in the above-referenced U.S. patent 
application, declare as follows: 

1 . Prior to March 31 , 2000, we jointly conceived, in the United States, of the claimed 
invention of detecting a network management event regarding the status of a 
node in the SS7 network and communicating the operational status information 
to nodes in the IP network 
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2. As evidence of our conception of the claimed invention prior to March 31, 2000, 
and our due diligence in reducing the invention to practice, we attach Exhibit A, 
which will now be explained in detail. 

3. Exhibit A is a copy of a portion of U.S. provisional patent application no. 

60/208,532, filed June 1, 2000. In particular, Exhibit A includes a document 

entitled "IP7 Secure Gateway 2.0 MTP Primitives," which describes technical 

features of the claimed invention developed by us. Activities relating to the 

development of the subject matter disclosed in the document occurred at the 

assignee's offices in Morrisville, North Carolina, USA. On page 2 of the 

document, it is indicated that the document was revised on August 2, 1999 and 

October 11, 1999. Thus, all of the contents of the document were generated at 

least as early as October 11, 1999, prior to March 31, 2000. The document in 

Exhibit A describes the MTP Primitives feature. The MTP Primitives feature 

relates to notifying the nodes in the IP network of the status of point codes in the 

SS7 network in response to network management event. For example, in §1.1, 

Purpose and Scope, the document states. 

This document describes the MTP Primitives feature (feature #009 
of [2]) that will be introduced in the IP 2.0 release. The status of the 
point codes in the SS7 networks needs to be made available to IP 
connected MGCs and IP-SCPs. This feature provides MTP status 
in the SS7 network to IP connected network elements through the 
MTP Primitives sent over the TALI protocol. The MTP Primitives 
function similar to the MTP3 network management procedures for 
TFA, TCA. TFP, TCP, TFC and UPU. The MTP Primitives function 
also provides the ability for an IP device to generate RCT 
messages. 

The passage above indicates that the MTP Primitives feature performs MTP3 
network management procedures for TFA, TCA, TFP, TCP, TFC and UPU, 
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which includes detecting network managennent events, and communicates point 
code status information to IP connected network elements. 

4. In Figure 1 on page 9 of the attached document, the signaling gateway detects 
certain network management events related to prohibited, allowed, and 
congested point codes and communicates that status information to IP nodes. 

5. We continuously worked on the MTP Primitives feature, which embodies the 
claimed steps of detecting a network management event regarding the status of 
a node in the SS7 network in communicating the operational status to selected 
nodes in the IP network, from its conception date of at least as early as August 2, 
1999, until the feature was reduced to practice. 
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1. INTRODUCTION 



1.1 Purpoise and Scope ^ 

This document describes the MTP Primitives feature (feature #009 of [2]) that will be introduced in the IP*' 2.0 
release. The status of the point codes in the SS7 networks needs to be made available to IP connected MGCs and 
IP-SCPs. This feature provides MTP status in the SS7 network to IP connected network elements through the MTP 
Primitives sent over the TALI protocol. The MTP Primitives function similar to the MTP3 network management 
procedures for TFA, TCA, TFP, TCP, TFC and UPU. The MTP Primitives function also provides the ability for an 
IP device to generate RCT messages. 

The benefits of this feature include: 

• Ability for an IP device to divert traffic from a SG that is not able to access a point code that the mated SO 
can access 

• Ability for an IP device to audit point code status 

• Ability for an IP device to build up routing tables before sending traffic (similar to MTP Restart feature) 

• Ability for an IP device to be warned about SS7 network congestion 

• Ability for an IP device to abate congestion 

• Ability for an IP device to obtain SS7 User Part Unavailability status 

This document will be used by designers to write design specifications, by test organizations to write test cases, and 
by the Customer Documentation Team to write customer documents. 

1.2 References 

[1] TEKELEC Acronym Guide, 070203MO.MWD, Revision 1 .14, Tekelec, August 1996. 

[2] IP'^ Secure Gateway 2 M Product Functional Specification, pf002525.doc, Revision 1.5, J. Mason, Sept. 1999. 

[3] Transport Adapter Layer Interface 2.0, tr002733.doc, Revision 1.2, M. Xu, Sept. 1999. 

[4] JP7 Release 2.0 Performance and Capacity Enhancements, fd002846.doc, Revision 1 .2, Brendes, Sept 1999. 

[5] TSRQ Detail Design Specification, 2dd201 13.doc, Revision 1.3, Tekelec, Feb 1996. 

[6] Maintenance Commands for IP7, cs002268.doc. Revision 1.15, Tekelec, Sept 1999. 

[7] Error Response on Input, cs000100.doc, Revision 1.173, Tekelec, Sept 1999. 

[8] IP7 Release 2.0 Routing Key Registration, fd002844.doc, Revision 1.0, Tekelec, Sept 1999. 

[9] LNP Platform FD, 2fd22098.doc, Revision 1.39, Tekelec, July 16, 1999. 

[I^^IMTP Restart, 2fd21006.doc, Revision 1.6, Tekelec, July 9, 1996. 

[1 \]Bell Communications Research Specification of Signalling System Number 7, GR-246-CORE, Issue 3, 
December 1998. 

1.3 Acronyms 

In addition to the acronyms defined in [1], the acronyms below are used in the document. 



Acronym 


Definition 


IP-NE 


Internet Protocol Network Element 


IP-SCP 


Internet Protocol Switching Control Point 


MGC 


Media Gateway Controller 


SG 


Secure Gateway 


TALI 


Transport Adoption Layer Interface 


Table 1 : List of Acronyms 
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2. GENERAL DESCRIPTION 

MTP status is provided by the Secure Gateway to the IP connected network elements through new TALI messages 
defined in [3]. The new TALI messages are: 

• Point Code Unavailable (PC UA) 

• Point Code Available (PC AV) 

• Request for Point Code Status (PC AUD) 

• Cluster Unavailable (CL UA) 

• Cluster Available (CL AV) 

• Request for Cluster Status (CL AUD) 

• Congested Destination, w/ Cong Level (CONG LVL) 

• Request for Congestion Status (CONG AUD) 

• User Part Unavailable (UP UA) 

This feature is for the SS7IPGW build only. The IPLIM GPL uses native MTP3 messages to communicate with its 
far end peer so there is no need to convert these messages to primitives. 

2.1 Terminology 

Some terms that are used tiiroughout the document need to be defined: 

1) Service PDU - MSU received from an IP node. These messages will have either the saal, mtp3, isot or seep 
opcode. 

2) Broadcast phase - autonomous notifications of point code/cluster changes that are transmitted to all IP nodes. 
Broadcasts will occur because of a receipt of a network management message or a link related event. 

3) Response method - primitives transmitted in response to previously sent service PDU firom an IP node. 

4) Audit - an on-demand request firom an IP node for either point code availability or congestion status. 
Throughout this document, the term audit, request and query are used interchangably. 

5) Primitive replication - a single event causing copying of a single primitive for transmission on multiple sockets. 
All broadcast phase primitives require replication. Some response method primitives require replication if the 
originating socket is not known. Further details can be found in Section 3.3. 

6) Capacity - maximum amount of offered load available for processing. The expected capacity is 1000/2000 
MSU/sec depending on the hardware used. For more information, please refer to [4]. 
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2.2 TALI MTPP Primitives 

The MTP Primitive (mtpp) message structure, as shown in Table 2, is defmed in [3] and repeated here for clarity. 



Octets 


Field Name 


Description 


0..3 


SYNC 


*TALr 


4,.7 


OPCODE 


*mgmt* 


8..9 


LENGTH 


Length 


10..13 


PRIMITIVE 


*mtpp* 


14.. 17 


Primitive OPERATION 


The OPERATION field specifies the 1 operation 
within the group of operations identified by the 
primitive. 


18... 


Message Data 


The content of the message data area is dependent on 
the combination of opcode/primitive/operation fields. 
Each of those combinations could use a different 
message data structure. 



Table 2: Message Structure for MTP Primitives 

The Primitive Operation and Message Data fields of the message, as shown in Table 3, is defined in [3] and repeated 
here for clarity. 



# bytes 


Field Name 


Description 


Type of Field 


2 


MTPP Operation 


Identifies which 'mtpp' operation/capability is 

provided in this message. 

This integer field uses the following encodings: 

0x0001 = Point Code Unavailable 

0x0002 = Point Code Available 

0x0003 = Request for Point Code Status 

0x0004 = Cluster Unavailable 

0x0005 = Cluster Available 

0x0006 = Request for Cluster Status 

0x0007 = Congested Destination, w/ Cong Level 

0x0008 = Request for Congestion Status 

0x0009 = User Part Unavailable 


Integer 


4 


Concemed Point Code 


Identifies the SS7 Point Code that is relevant to the 
mtpp operation. The mtpp operation is concerning this 
pt code (or cluster). 


SS7 Pt Code 



Title: IP7 Secure Gateway 2.0 MTP Primitives Feature Description 
Doc No.: Fd0027822 |PVCS#: 1.1 
Page 7 of 29 



# bytes 


Field Name 


Description 


Type of Field 


4 


Source Point Code 


This field is only used on the 'Congested Destination' 
and 'Request for Congestion Status' operations. 

• When used in an 'Congestion Destination' 
operation, this field contains the Pt Code of the 
Source of the traffic that was experiencing 
congestion as it made its way to the Concerned Pt 
Code. In terms ofthe original SS7MSUS (the 
TransFer Controlled MSU) that provided 
congestion information, the CPC of the TFC is the 
'Concemed Point Code' ofthe resulting MTPP 
primitive and the DPC ofthe TFC is the 'Source 
Point Code' ofthe resulting MTPP primitive. 

• When used in an 'Request for Congestion Status' 
operation, this field indicates which Source Pt 
Code is trying to abate the congestion of the 
concerned Pt Code. In terms ofthe ongmal SS7 
MSUs (the Route Congestion Test MSU) that is 
used to poll for congestion, the DPC of the RCT is 
the 'Concerned Point Code' ofthe MTPP 
primitive and the OPC of the RCT is the 'Source 
Point Code' ofthe MTPP primitive. 


SS7 Pt Code 


2 


Congestion Level 


This field is used on the 'Congested Destination' and 

'Request for Congestion Status' operations to indicate 

the congestion level ofthe destination. 

This integer field uses the following encodings: 

0x0000 = Congestion Level 0 

0x0001 = Congestion Level 1 

0x0002 = Congestion Level 2 

0x0003 = Congestion Level 3 


Integer 


2 


Cause Code 


This field is used on the 'User Part Unavailable' 
operation to indicate the Cause Code for why the UPU 
is being sent. 

This integer field uses the following encodings: 
0x0000 = Cause Unknown 
0x0001 = User Part Unequipped 
0x0002 = User Part Inaccessible 


Integer 


2 


User ID 


This field is used on the 'User Part Unavailable' 
operation to indicate which user part is unavailable. 


Integer 



Table 3: Message Data Structure to be used with the 'rntpp' PRIMITIVE 
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Table 4 indicates the Required (R), Conditionally Required (CR), or Not Applicable (NA) status for each field of the 
message data structure in Table 3 based on the MTPP Operation field. As mentioned previously, unused fields 
(those marked NA) should be initialized to 0 by the sender and ignored by the receiver. 



rieiu 

Onerafion 


^oucemeu. 
Pt Code 


OOUICC 

Pt Code 


v^ongesiion 
Level 


Cause Code 


T TcAr in 
user Ulj 


Point Code Unavailable 


R 


NA 


NA 


NA 


NA 


Point Code Available 


R 


NA 


NA 


NA 


NA 


Request for Point Code Status 


R 


NA 


NA 


NA 


NA 


Cluster Unavailable 


R 


NA 


NA 


NA 


NA 


Cluster Available 


R 


NA 


NA 


NA 


NA 


Request for Cluster Status 


R 


NA 


NA 


NA 


NA 


Congested Destination, w/ Cong Level 


R 


R 


R 


NA 


NA 


Request for Congestion Status 


R 


R 


R 


NA 


NA 


User Part Unavailable 


R 


NA 


NA 


R 


R 



Table 4: Required/Conditionally Required/Not Applicable Fields for each MTPP Operation 



Figure 1 shows the MTP Primitives that flow between the SG and an IP node. In addition, the SS7 network 
management messages that concern the MTP Primitives feature are shown between the SG and a remote SS7 
network element. Not all SS7 management messages, such as changeover, are shown even though they may have a 
relationship to the MTP Primitives. 



RCT 



Remote SS7 
Network 
Element 



SG 



PC AUD 
CL AUD 
CONG AUD 
EN BCAST 
DS BCAST 
EN RESP 
DS RESP 



IP node 



TFP 
TFA 
TFC 
UPU 



PC UA 
PC AV 
CL UA 
CL AV 
UP UA 
CONG LVL 



Figure 1: Primitive Flow with External Devices 
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Figure 2 shows the MTP Primitives that flow between the layers of the SG. In addition the SS7 network 
management messages that concern the MTP Primitives feature are shown between the MTP3 and Gateway Layer. 



TFP 
TPA 
TCP 
TCA 
UPU 
TFC 



PC UA 
PC AV 
CL UA 
CL AV 
UP UA 
CONG LVIi 



MTP3 



Gateway 
Layer 



TCP/IP 
Layer 



RCT 



PC AUD 
CL AUD 
CONG AUD 
EN BCAST 
DS BCAST 
EN RESP 
DS RESP 



Figure 2: Primitive Flow within the SG 

As shown in Figure 1 the SG is not expecting to receive point code/cluster availability/unavailability or congestion 
level prmutives. The SG will discard these primitives if they are received. The NA in the Received column in 
Table 5 mdicates this. 



As a matter of fact, the MTP Primitives are not intended for SG to SG communication. SG to SG communication is 
expected to use IPLIM links that uses native MTP3 for communication. 

The Transmitted column of Table 5 indicates which primitives are transmitted from the SG and when. Note that NA 
means the SG doesn't send the primitive. 



Primitive 


Broadcast 
phase 


Response 
method 


In Reply 
to an 
Audit 


Transmitted 


Received 


Point Code Unavailable (PC UA) 


Yes 


Yes 


Yes 


Yes 


NA 


Point Code Available (PC AV) 


Yes 


No 


Yes 


Yes 


NA 


Request for Point Code Status (PC AUD) 


NA 


NA 


NA 


No 


Yes 


Cluster Unavailable (CL UA) ~ 


Yes 


Yes 


Yes 


Yes 


NA 


Cluster Available (CL AV) 


Yes 


No 


Yes 


Yes 


NA 


Request for Cluster Status (CL AUD) 


NA 


NA 


NA 


No 


Yes 


Congested Destination, w/ Cong Level (CONG LVL) 


No 


Yes 


No 


Yes 


NA 


Request for Congestion Status (CONG AUD) 


NA 


NA 


NA 


No 


Yes 


User Part Unavailable (UP UA) 


No 


Yes 


No 


Yes 


NA 



Table 5: Primitive Communication 
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The mapping of events and their corresponding actions for this feature is shown in Table 6. The three reasons an IP 
device will receive primitives are broadcast phase state change notifications, response method notifications and 
responses to status queries. Both the broadcast phase and response method requires the IP device to enable 
transmission of these primitives as described in Section 3.1. If the IP device doesn't send any queries, it won't 
receive any responses to queries. 







Event 


Action 


Socket used for transmission 


Broadcast 
Phase 


1 


MTP3 sends Gateway Layer ItV 
for IP Node 


Gateway Layer sends PC UA to IP 
Node(s) 


RcnlicatpH tn all wTiirli Vmx/*» 

broadcast phase primitives enabled 


2 


M IP3 sends Gateway Layer TCP 
for IP Node 


Gateway Layer sends CL UA to IP 
Node(s) 


Replicated to all which have 

broadcast nhacp nrimifivpc *»'n!iV»1*ifl 




3 


MTP3 sends Gateway Layer TFA 
for IP Node 


Gateway Layer sends PC AV to IP 
Node(s) 


Replicated to all which have 
broadcast phase primitives enabled 




4 


MTP3 sends Gateway Layer TCA 
for IP Node 


Gateway Layer sends CL AV to IP 
Node(s) 


Replicated to all which have 
broadcast phase primitives enabled 


Response 
Method 


5 


MTP3 sends Gateway Layer UPU 
for IP Node 


Gateway Layer sends UP UA with 
cause code based on UPU 


Replicated to all 'which have response 
method primitives enabled and socket 
matches criteria defined in Section 3.4 


6 


MTP3 sends Gateway Layer TFC 
for IP Node 


Gateway Layer sends CONG LVL 
with cause code based on TFC 


Replicated to all which have response 
method primitives enabled and socket 
matches criteria defined in Section 3.4 




7 


IP Node sends Gateway Layer 
service PDU and DPC is 
imavailable 


Gateway Layer sends PC UA to IP 
Node 


Same socket service PDU received if 
response method primitives are 
enabled 




8 


IP Node sends Gateway Layer 
service PDU and cluster is 
unavailable 


Gateway Layer sends CL UA to IP 
Node 


Same socket service PDU received if 
rcdpuiidc incinuQ primiiives are 
enabled 




9 


IP Node sends Gateway Layer PC 
AUD and PC is unavailable as 
detennined by criteria in Table 1 1 


Gateway Layer sends PC UA or CL 
UA to IP Node 


Same socket PC AUD received 


Audit 


10 


IP Node sends Gateway Layer PC 
AUD and PC is available as 
determined by criteria in Table 1 1 


Gateway Layer sends PC AV to IP 
Node 


Same socket PC AUD received 


11 


IP Node sends Gateway Layer CL 
AUD and cluster is unavailable as 
determined by criteria in Table 1 1 


Gateway Layer sends CL UA to IP 
Node 


Same socket CL AUD received 




12 


IP Node sends Gateway Layer CL 
AUD and cluster is available as 
determined by criteria in Table 1 1 


Gateway Layer sends CL AV to IP 
Node 


Same socket CL AUD received 




13 


IP Node sends Gateway Layer 
CONG AUD 


Gateway Layer builds and transmits 
RCT to MTP3 for routing 


N/A 



Table 6: MTP Primitive Event/Action Mapping 
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3. DETAILED DESCRIPTION 



3.1 Transmission Filtering 

The Socket Options Registration Primitive (sorp) message, as shown in Table 7, is defined in [3] and repeated here 
for clarity. The Primitive Operation and Message Data fields of the message, as shown in Table 8, is defined in [3] 
and repeated here for clarity. This primitive allows an IP device to dynamically enable/disable the SG transmitting 
of broadcast phase and response method MTP Primitives. Only Bits 0 and 1 of the SORP flags are of concern for 
this feature. Broadcast phase and response method filtering are independent of each other. 



Octets 


Field Name 


Description 


0..3 


SYNC 


TALF 


4..7 


OPCODE 


'mgmt' 


8..9 


LENGTH 


Length 


10..13 


PRIMITIVE 


'sorp' 


14..17 


Primitive OPERATION 


The OPERATION field specifies the 1 operation 
within the group of operations identified by the 
primitive. 


18... 


Message Data 


The content of the message data area is dependent on 
the combination of opcode/primitive/operation fields. 
Each of those combinations could use a different 
message data structure. 


Table 7: Socket Options Registration Primitive 



# bytes 


Field Name 


Description 


Type of 
Field 


2 


SORP Operation 


Identifies which *sorp' operation/capability is provided in 
this message. 

This integer field uses the following encodings: 
0x0001= Set SORP Flags 
0x0002 = Request Current SORP Flags Settings 
0x0003 = Reply w/ Current SORP Flag Settings 


Integer 


4 


SORP Flags 


A 4 byte bit-field that uses each bit as an enabled/disabled 
flag for a particular socket option. 
Bit 0 is the least significant bit, bit 3 1 is the most 
significant bit. 

Bit X = 0 indicates the option is DISABLED. 
Bit X = 1 indicates the option is ENABLED. 

The assigtiments for each BIT are as follows 
Bit 0 = Broadcast Phase MTPP Primitives 
Bit 1 = Response Method MTPP Primitives 
Bit 2 = Normalized SCCP 
Bit 3 = Normalized ISUP 


Bit-Field 



Table 8: Message Data Structure to be used with the *sorp' PRIMITIVE 

Each socket will default to disable broadcast phase and response method MTP Primitives option. By defaulting to 
not enabling primitives, the sockets will act the same as they did for TALI 1.0. A socket will retum to its default 
settings once the socket closes. Therefore, after a socket is reconnected, the IP device is expected to retransmit its 
'sorp' configuration request. In addition, an IP device can change its filtering preference after a connection has been 
established. The SOCKSTATE PASS command, as described in Section 4.7.1, will be modified to display the 
current settings for the dynamically registered socket options. 
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3.2 Congestion Abatement 

When a service PDU encounters a congested link, a TFC will be returned to the originator of the service PDU with 
the concerned point code indicating which node is in congestion. When the Gateway layer on the SG receives the 
TFC, the TFC will be converted to a CONG LVL primitive and will be sent to all the IP-NEs that match socket 
selection criteria described in Section 3.4. The concerned point code field in the CONG LVL primitive will be set 
to the destination field of the TFC message. The source point code in the CONG LVL primitive will be set to the 
DPC of the TFC. The congestion level in the CONG LVL primitive will be set to the status field of the TFC. Table 
9 shows how the following TFC will be converted to a CONG LVL primitive. 

The format of the TFC message is shown below for clarity: 



*** Start of 

003 10000000 

0000 

—00 

10 

004 00000100 

005 00000100 

006 00000100 

007 00000011 

008 00000011 

009 00000011 

010 00000001 



MTP Level 3 *** 
MSU 

80 

Service Indicator 

Network Priority 

Network Indicator 
04 Destination Point Code 
04 
04 

03 Origination Point Code 

03 

03 

01 Signaling Link Selection 



0000 - Network Mgmnt. 
priority 0 
National Network 



00 
10 
4-4 



-4 



3-3-3 



*** start of 

011 00100011 

0011 

0010 

012 00000101 

013 OOOOOlOl 

014 OOOOOlOl 

015 00000010 

10 

000000 — 



Network Management *** 
Transfer-controlled 

23 Heading Code 
Heading Code 0 
Heading Code 1 

05 Destination 

05 

05 

02 

Status 
Spare 



03 
02 

5-5- 



10 - status 2 
00 



Octets 


Field Name 


Value 


0..3 


SYNC 


TALI* 


4..7 


OPCODE 


*mgmt' 


8..9 


LENGTH 


22 


10..13 


PRIMITIVE 


'mtpp' 


14.. 17 


MTPP OPERATION 


0x0007 = Congested Destination, w/ Cong Level 


18..21 


Concerned Point Code 


5-5-5 


22..25 


Source Point Code 


4.4-4 


26..27 


Congestion Level 


0x0002 = Congestion Level 2 


28..29 


Cause Code 


0 


30.31 


User ID 


0 



Table 9: CONG LVL Example 
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This feature provides the tools that allow the IP node to abate this congestion via the CONG AUD and CONG LVL 
primitives. The IP-NE is responsible for abating the congestion. To abate the congestion, an IP-NE will request the 
current congestion level for a point code using the GONG AUD primitive. The SG will generate a signaling-route- 
set-congestion-test (RCT) message on behalf of the IP-NE and route the message through the network. The IP-NE 
should generate a CONG AUD primitive with the following fields: 

1 . Concerned Point Code - congested point code returned in the CONG LVL primitive 

2. Source Point Code - point code to be used as the OPC of the RCT 

3. Congestion Level - congestion level to abate based on the congestion level returned in the CONG LVL 
primitive 

. 4. Cause Code and User ID - should be initialized to 0 



The source point code field is used in determining the requestor when a single socket is connected to multiple point 
codes. Consider the routing key table shown in Table 10. If a CONG AUD primitive is received on socket SS3, the 
SG doesn't know which point code to use as the OPC in the RCT message. Therefore, the source point .code field of 
the primitive will be used for this purpose. 



Socket 


DPC 


SI 


SSN 


OPC 


CICS 


CICE 


SSI 


1-1-1 


0 


X 


X 


X 


X 


SS2 


1-1-1 


0 


X 


X 


X 


X 


SS3 


1-1-1 


0 


X 


X 


X 


X 


SS3 


1-1-2 


1 


X 


X 


X 


X 


SS3 


1-1-3 


2 


X 


X 


X 


X 


SS3 


1-1-4 


0 


X 


X 


X 


X 


SS4 


1-1-4 


1 


X 


X 


X 


X 


SS5 


1-1-2 


5 


X 


6-6-1 


1 


100 



Table 10: Routing Key Table 



Another issue to be addressed is when multiple EP devices try to abate congestion for a single point code. Assimae a 
service PDU is sent from socket SSI and encounters a congested link. A TFC will be returned to the SG with the 
DPC set to 1-1-1. Since the SG has no knowledge of the socket that transmitted the original service PDU, a CONG 
LVL primitive will be transmitted to sockets SSI, SS2 and SS3 (assuming response method primitives are enabled). 
The source point code in the primitive will be set to 1-1-1 . The IP devices connected to these 3 sockets could then 
each send a CONG LVL primitive to abate this congestion. To avoid multiple RCT messages concerning the same 
point code being sent from SG (multiple IP-NEs trying to abate congestion level of same point code), the SG 
maintains a list of point codes for which RCT messages have been sent and it suppresses duplicate RCTs to the same 
point code. A duplicate RCT is one which the concerned point code and source point code are identical to a 
previous request for congestion status. 

The hst is maintained for 40 point codes, and the entries are time stamped when the entry is written to the table. An 
entry is stored in the table only for 0.5 sec. After 0.5 sec, the entry(s) will be removed. When the table is full, if the 
SG receives a CONG AUD primitive for a point code that is not in the list, a RCT message will be generated but the 
point code will not be stored in the table. 
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The format of the RCT message is shown below for clarity: 



*** Start of MTP Level 3 *** 
MSU 

003 00000000 00 

0000 Service Indicator 

— 00 Network Priority 

00 Network Indicator 

004 00000000 CO Destination Point Code 

005 00000000 00 

006 00000000 00 

007 00000000 00 Origination Point Code 

008 00000000 00 

009 00000000 00 

010 00000000 00 Signaling Link Selection 



0000 - Network Mgmnt. 

00 - priority 0 

10 - National Network 

0-0-0 



0-0-0 



*** Start of Network Management *** 

Route-set-congestion-test 

Oil 00010011 13 Heading Code 

0011 Heading Code 0 03 

0001 Heading Code 1 01 



The above RCT message will use the following fields modified: 

• The DPC needs to be set to the concerned point code value in the CONG AUD primitive 

• The OPC needs to be set to the source point code value in the CONG AUD primitive 

• The SLS needs to be randomized 

• The Networic Priority needs to be set to the congestion level value in the CONG AUD primitive 



3.3 Primitive Replication 

The TFP, TCP, TFA, TCA, UPU and TFC MSUs sent from MTP3 to the Gateway Layer are converted into a 
primitive to be sent to potentially many sockets. Since there may be up to 50 sockets associated with a single 
destination point code, each message could result in 50 TALI messages. This one to many replication can generate a 
large number of TALI messages. The handling of this traffic is discussed in Section 3.6. 



Title: IP7 Secure Gateway 2.0 MTP Primitives Feature Description 
Doc No.: Fd0027822 | PVCS #: 1.1 
Page 15 of 29 



3.4 Socket Selection 
3.4.1 Broadcast Phase 

The broadcast phase MSUs listed as the first four events in Table 6 will need to be sent to every socket which has 
broadcast phase enabled. 



3.4.2 Response Method TFCs/UPUs 

For response method TFCs and UPUs (events 5 and 6 in Table 6), the response method parameter must be enabled 
as well as performing the following steps: 



1 . Check the route key table and make a list of every entry that: 

i) If SI is ISUP (5), the DPC in the route key table entry matches the DPC of the message and the OPC in 
the route key table entry matches the concerned point of the TFCAJPU 

ii) If SI is not ISUP (5), the DPC in the route key table entry matches the DPC of the message 

2. Send primitive to every socket in the list 



Note: 

1 . TFC & UPU messages are always considered as response method messages. 

2. TFP & TCP messages will be considered response method messages only if a valid socket index in the message, 
otherwise they will considered as broadcast method messages 

3. TFA & TCA will always considered as broadcast phase messages. 



3.4.3 Response Method TFPs/TCPs 

The response method TFPs and TCPs (events 7 and 8 in Table 6) will need to be sent to the socket which the 
original PDU was received on if response method is enabled. 

Currently as TALI messages are received, the socket index is stored m the extended data area of the system buffer 
containing the PDU. The downside of this is that the extended data area is not protected from being overwritten. 
For this feature, the socket index will be stored in the overhead portion of the system buffer as well as a flag to 
indicate if the socket index is vahd for messages received and for response method TFPs/TCPs that came down to 
level 2 for transmission. This will be used for determining whether a TFP/TCP is a broadcast phase or a response 
method. 
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3.5 Point Code Availability Determination 

Both point code audit (PC AUD) and cluster audit (CL AUD) primitives require determination of a point code's 
availability. Various rules apply for making this determination and are documented in Table 1 1. The criteria for 
making this determination are summarized as follows: 

• True Point Code - the concerned point code specified in the audit primitive is the SG's true point code 

• Capability Point Code - the concerned point code specified in the audit primitive is a capability point code for 
theSG 

• SCCP service allowed - indicates if the capability point code is allowed based on the status of the SCCP card 
and the status of the local subsystem associated with the CPC 

• Route exists in Table - indicates point code was entered in the destination table via the ENT-DSTN command. 
This is not to be confused with the IP7 routing key table. If not found and concerned point code is an ANSI full 
point code, a lookup for the corresponding cluster is performed. 

• ANSI - byte 3 of SS7 Point Code structure as defmed in [3] indicates if point code is ANSI or ITU 

• Cluster unknown - A cluster is unknown if the following are true: 

1 . there is no provisioned cluster entry for the route key 

2. there is no full point code or true/capability point code entry that matches the cluster 

• Danger of Circular Routing - indicates possibility of circular routing as determined by existing SG rules 

• Destination Accessible - indicates a route is available to the DPC 



Home Cluster - indicates if the SG*s true point code or any of its CPCs are a member of a provisioned cluster 



Primitive 


True 


Capability 


SCCP 


Route 


ANSI 


Cluster 


Danger 


Destination 


Home 


Primitive 


Received 


Point 


Point 


service 


exists 




unknown 


of 


Accessible 


Cluster 


Transmitted 




Code 


. Code 


allowed 


in 






Circular 
















Table 






Routing 








PC AUD 


Y 


N 


X 


X 


X 


X 


X 


X 


X 


PCAV 




N 


Y 


Y 


X 


X 


X 


X 


X 


X 


PC AV 




N 


Y 


N 


X 


X 


X 


X 


X 


X 


PCUA 




N 


N 


X 


N 


Y 


Y 


X 


X 


X 


CLUA 




N 


N 


X 


N 


Y 


■ N 


X 


X 


X 


PC UA 




N 


N 


X 


N 


N 


X 


X 


X 


X 


PCUA 




N 


' N 


X 


Y 


X 


X 


Y 


X 


X 


PCUA 




. N 


N 


X 


Y 


X 


X 


N 


N 


X 


PCUA 




N 


N 


X 


Y 


X 


X 


N 


Y 


X 


PC AV 


CLAUD 


X 


X 


X 


N 


X 


Y 


X 


X 


X 


CLUA 




X 


X 


X 


N 


X 


N 


X 


X 


X 


CL AV^ 




X 


X 


X 


Y 


X 


X 


Y 


X 


N 


CLUA 




X 


X 


X 


Y 


X 


X 


N 


N 


N 


CLUA 




X 


X 


X 


Y 


X 


X 


N 


Y 


N 


CL AV^ 




X 


X 


X 


Y 


X 


X 


X 


X 


Y 


CL AV^ 



Y=Yes, N=No, X=Don't care 



Table 11: Point Code Availability Rules 

Notes: 

1 . If a service PDU is received with a true point code and SCCP service not allowed, MTP3 would return a 
response method UPU. An audit of this point code will result in a PC AV being transmitted. 

2. These queries will not affect the stopping of MTP3 T8 and T18 timers like RSx/RCx messages would. 
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The following point code audits will be discarded: 

• Any audit received during full restart. 

• Audit request would cause card level congestion. 

• Cluster audits that provide a full point code instead of cluster point code. 

• Point code audits that provide a cluster point code instead of a full point code. 

• Cluster/Point code audits that provide an illegal point code format. 

3.6 Capacity 

MTP Primitives received from the IP-NEs will be counted towards rated receive capacity of SG and MTP primitives 
that are transmitted from the SG to IP-NEs will be counted towards the rated transmission capacity of the SG. 




PDUs 



tx_tb_q 
(PDU Queue) 



TALI Tx 
queue 



Requries Tx capacity to 
exit 



Figure 3: MTP Primitives capacity 

MTPP primitives and the normal PDU traffic will be combined for transmission to TALI layer as shown in the 
above figure. If the total number of messages (PDU + MTPP primitives) is above the rated capacity of the SG the 
Imk will go mto congestion and the PDU will be discarded based on the congestion level of the link. 

Illustration of congestion based on 2000 MSU/Sec rated capacity of SG: 

If there were 1990 PDU/Sec being transmitted to TALI queue, and if there is 1 broadcast message that needs to be 
replicated to 10 sockets, the total number of PDU transmitted will be 2000. If there is one additional PDU/sec 
then PDU transmission will be delayed by 1 second. For each additional second one PDU will be delayed and if this 
contmues for 1000 seconds, there will be 1000 PDUs delayed, which will fill up the congestion queue. The card 
enters congestion when the congestion queue is full. 
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3.7 Card Level Congestion 

For determination of congestion, number of messages in three different queues will be summed and compared to the 
congestion threshold table (Congestion threshold table is not modified for this feature). The three different queues 
are: 

• PDU queue 

• L3_L2_q 

• Primitives queue 

This feature will provide depth of the primitives queue for use in the card level congestion calculation since 
it represents outstanding level 2 work. 



3.8 User Part Unavailability Mapping 

When the Gateway layer on the SG receives an UPU, the UPU will be converted to an UP UA primitive and will be 
sent to all the EP-NEs that match socket selection criteria described in Section 3.4. The concemed point code field 
in the UP UA primitive will be set to the destination field of the UPU message. The cause code in the UP UA 
primitive will be set to the unavailable cause code field of the UPU. Table 12 shows how the following UPU will be 
converted to an UP UA primitive. 

The format of the UPU message is shown below for clarity: 

***. Start of MTP Level 3 *** 
MSU 

003 10000000 80 

0000 Service Indicator 

— 00 Network Priority 

10 Network Indicator 

004 00000001 01 Destination Point Code 

005 00000001 01 

006 00000001 01 

007 00000010 02 Origination Point Code 

008 00000010 02 

009 00000010 02 

010 00000000 00 Signaling Link Selection 



0000 - Network Mgmnt. 

00 - priority 0 

10 - National Network 

1-1-1 



2-2-2 



*** Start of Network Management *** 

User Part Unavailable 
la Heading Code 
Heading Code 0 
Heading Code 1 
Destination 



011 00011010 

1010 

0001 

012 00000011 

013 00000011 

014 00000011 

015 00100011 

0011 

0010 



03 
03 
03 
23 



User ID 

Unavailable Cause Code 



10 
01 

3-3-3 



0011 - SCCP 

0010 - Inaccessible remote user 



Octets 


Field Name 


Value 


0..3 


SYNC 


TALF 


4..7 


OPCODE 


'mgmt' 


8..9 


LENGTH 


22 


10.. 13 


PRIMITIVE 


*mtpp' 


14..17 


MTPP OPERATION 


0x0009 = User Part Unavailable 


18..21 


Concerned Point Code 


3-3-3 


22..25 


Source Point Code 


0 


26..27 


Congestion Level 


0 


28..29 


Cause Code 


0x0002 = User Part Inaccessible 


30..31 


User ID 


3 - SCCP 


Table 12: UP UA Example 
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4. FUNCTIONAL REQUIREMENTS 



4.1 PFS Compliance Matrix 

FC — Fully compliant PC 



Partially compliant 



NA 



Not applicable 









[R0009-1] 


FC 


FD-l 


[R0009-2] 


FC 


FD-2 


[R0009-3] 


FC 


FD-3 


[R0009-4] 


FC 


FD-4 


[R0009-5] 


FC 


FD-5 


[R0009-6] 


FC 


FD-6 


[R0009-7] 


FC 


FD-7 



Table 13: PFS Compliance Matrix 



4.2 PFS Requirements 

The requirements for this feature as defined in [2] are repeated here for clarity of reading. Certain assimiptions are 
made with these requirements concerning exceptional situations. For example, the Broadcast Exception Indicator 
(BET) will prevent any broadcast phase primitives from being transmitted even if sockets are enabled to transmit 



FD Req't # 


Required or Optional 
fR nr 0^ 


Requirement Description (and any additional comments if 
necessary) . 


Affected GPLs 


FD-1 


R 


The sending of Primitives shall be configurable on a socket basis 
via inband registration. 


SS7IPGW 


FD-2 


R 


The Secure Gateway shall provide an indication to all EP devices, 
via a point code/cluster imavailable message, when a point code 
has become unreachable 


SS7IPGW 


FD-3 


R 


The Secure Gateway shall send a point code/cluster unavailable to 
an IP device in response to a point code status message if the 
specified point code/cluster is unavailable. The indication will be 
sent back to the requestor via the same socket which the request 
was received. 


SS7IPGW 


FD-4 


R 


The Secure Gateway shall send a point code/cluster unavailable to 
an IP device in response to a service message if the destination 
point code/cluster is imavailable. The indication will be sent back 
to the requestor via the same socket which the service message 
was received. 


SS7IPGW 


FD-5 


R 


The Seciue Gateway shall provide an indication to all IP devices, 
via a point code available/cluster message, when a point 
code/cluster has become available 


SS7IPGW 


FD-6 


R 


The Secure Gateway shall send a point code/cluster available to an 
IP device in response to a point code/cluster status message, if the 
specified point code/cluster is available. The indication will be 
sent back to the requestor via the same socket which the request 
was received. 


SS7IPGW 


FD-7 


R 


For TFCs destined for an IP node, the Secure Gateway shall send 
congestion level indication to all IP devices that match the 
destination point code from the TFC. The congestion level in the 
TFC will be used for the congestion level in the indication. 


SS7IPGW 



Table 14: PFS Requirements 
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4.3 General Requirements 



FD Req't # 


Required or Optional 
(Ror O) 


Requirement Description (and any additional comments if 
necessary) 


Affected GPLs 


FD-8 


R 


MTPP audit pnmitives shall be discarded if the total number of 
messages in the three queues mentioned in the section 3.7 is 
above the max bfr cnt value of congestion threshold table 


SS7IPGW 


FD-9 


R 


Pomt code/cluster availabihty/unavailability or congestion level 
primitives shall be ignored if received by the SS7IPGW card 


SS7IPGW 


FD-10 


R 


The Concerned Pomt Code parameter of all MTP Primitives 
received shall be validated as a valid point code. The validation 
consists of verifying byte 3, which indicates the type of point 
code, conforms to the defmition provided by Table 10 of [3]. 
Otherwise, the primitive will be discarded. 


SS7IPGW 


FD-11 


R 


The Source Point Code parameter of the Request for Congestion 
Status Primitive (CONG AUD) shall be validated as a valid point 
code. The vaHdation consists of verifying byte 3, which indicates 
the type of point code, conforms to the defmition provided by 
Table 10 of [3]. Otherwise, the primitive will be discarded. 


SS7IPGW 


rD-12 


R 


The congestion level parameter in the CONG AUD primitive 
shall be validated as a valid congestion level. The vahdation 
consists of verifying the level conforms to the definition provided 
by Table 19 of [3]. Otherwise, the primitive will be discarded. 


SS7IPGW 


FD-13 


R 


The Primitive Operation field of each received primitive will be 
validated as a valid operation value. The validation consists of 
verifying the value conforms to the defmition provided by Table 
19 of [3]. Otherwise, the primitive will be discarded. 


SS7IPGW 


FD-14 


R 


Each non-discarded congestion request primitive shall generate a 
RCT MSU with the DPC, OPC and network priority based on the 
data in the congestion request primitive. 


SS7IPGW 


FD.15 


R 


xid^H dppiicauon socKeis win aetault to disable broadcast phase 
and response method primitive transmissions and return to 
default state when the socket closes. The IP device is responsible 
for re-enabling the primitives. 


SS7IPGW 


FD-16 


R 


Each transmitted primitive shall be counted as one unit of work 
with respect to the transmit capacity. 


SS7IPGW 


FD-17 


R 


Each received primitive shall be counted as one unit of work with 
respect to the receive capacity. 


SS7IPGW 



Table 15: General Requirements 



4.4 Hardware Requirements 

NOT APPLICABLE 

4.5 Database Requirements 

NOT APPLICABLE 

4.6 Upgrade Considerations 

MTP Primitives are prevented from being sent to nodes running the TALI 1.0 interface. 
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4-7 User Interface Requirements 

The two major user interface changes for this feature allow the registering of sockets to transmit primitive 
broadcasts and the display of primitive measurements. 



FD Req't # 


Required or Optional 
(Ror O) 


User Interface Requirement Description (and any additional 
comments if necessary) 


Affected GPLs 


FD-18 


R 


The MSUCOUNT PASS command shall be modified to display 
measurements on a per link basis related the number of 
primitives transmitted, received and discarded. 


SS7IPGW 


FD-19 


R 


The SOCKSTATE PASS command shall be modified to display 
the version of TALI the far end is using and which MTP 
Primitives are enabled. 


SS7IPGW 



Table 1 6: User Interface Requirement Table 

User interface requirements in the Eagle consists of administration and maintenance capabUities. This document has 
provided an overview of these areas, as they relate to this feature. Table 17 lists the commands affected along with 
the anticipated changes necessary for this feature. 



Command 


Changes 


pass:loc^xxx:cmd-"sockstate" 


Display TALI version and MTP Primitives enabled 


pass : loc=xxxx: cmd=' 'msucount' ' 


Display MTP Primitive measurements 



Table 17: Affected Commands 



The command examples m the following subsections are provided to enhance understanding of the requirements and 
to provide one suggestion for names and output. The complete requirements and functions of the changed 
comniands will be described in detail in their associated Command Specifications. These documents will also 
provide &e actual parameter names, valid values, and output for the commands. The lists of command specification 
affected by this feature are shown in Table 18. 



Document # 


Document Name 


Changes 


CS002268.DOC 


Maintenance Commands for IP7 


changes for sockstate and msucount 



Table 18: Affected Command Specifications 
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4.7.1 SOCKSTATE Pass Command 

The SOCKSTATE pass command will be modified to display which MTP Primitives are enabled and the TALI 
interface version number. 

> pass :loc=1105:cmd="sockstate c7000" 

SOCKSTATE; Socket state history log 

Current settings: -i service tali 

MTP Primitives broadcast phase: enabled 

MTP Primitives response method: enabled 

Normalized SCCP: disabled 

Normalized ISUP: disabled 

Near End TALI version: 2.0 

Far End TALI version: 2.0 

Negotiated TALI version: 2.0 

Date Time Socket Event 



99-04-08 10:01:33.570 Socket Created 

99-04-08 10:04:21.765 Socket Allowed for Traffic 

99-04-08 10:04:55.405 Management Socket Open 

99-04-08 • 10:06:12.030 Link Activated 

99-04-08 10:06:12,030 Transition to Connecting 

99-04-08 10:06:17.860 Socket Connection Established 

99-04-08 10:06:17.860 .Transition to NEA-FEP 

99-04-08 10:06:17.865 Transition to NEA-FEA 

99-04-08 10:16:57.190 Monitor Message Transmitted 

99-04-08 10:16:57.200 Monitor-Ack Message Received 

99-04-08 10:16:58.170 Test Message Transmitted 

99-04-08 10:16:58.180 Allow Message Received 



99-04-08 10:20:55.480 
99-04-08 10:20:55.480 
99-04-08 10:20:55.890 



Test Message Transmitted 
Allow Message Received 
SCCP MSU Transmitted 
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4.7,2 MSUCOUNT Pass Command 

The MSUCOUNT pass command will be modified to display primitive measurement counts. The three counts will 
only be displayed on a per link basis and will indicate 

1 . total number of primitives received which includes received queries processed and received primitives that were 
discarded 

2. total number of received primitives that were discarded which includes excessive query requests and non- 
queries received 

3. total number of primitives transmitted which includes all the replicated primitives 



Link Measurements 



Transmit Count Total 



tx bytes : 
tx msus : 



00000 
00000 



Transmit Discard Counts 



discarded tx due to special adjpc msu: 00000 

discarded tx due to discard all adjpc msu: 00000 

discarded tx due to no ss7 rtbl entry: 00000 

discarded tx due to no ss7 rtkey: 00000 

discarded tx due to no sock avail to pc: 00000 
discarded tx due to no sock avail to rtkey: 00000 

discarded tx due to all sock congested: 00000 

discarded tx due to seep msg type: 00000 

discarded tx due to seep class: 00000 

Receive Count Total 



rev bytes: 00000 
rev msus: ^ 00000 

Receive Discard Counts 



discarded rev due to link state: 00000 

discarded rev due to seep msg type: 00000 

discarded rev due to seep class: 00000 

discarded rev due to seep called party: 00000 

discarded rev due to seep calling party: 00000 

discarded rev due to isup sic: 00000 

MTPP MGMT Primitive Totals 



MTPP primitives received 00000 

MTPP primitives discarded 00000 

MTPP primitives transmitted 00000 

Stored Transmit Discard Data 



no stored transmit discard data 



Stored Receive Discard Data 



no stored receive discard data 
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4.8 TALI Requirements 

Table 19 specifies the requirements for the TALI Layer for this feature. 



FD Req't # 


Required or Optional 
(Ror 0) 


Reouirement Descrintinn (ami anv ariHiHnnoi ^^^^^^ ^^^^ 
<^M>« wmAAWAAt. A^vo^i t^iitfii ^<tiiu ally AuuiiionHi comments it 

necessary) 


Affected GPLs 


FD-20 


R 


The TALI layer shall provide on a per-socket basis a string 
indicating what version of the TALI interface that the SG is 
capable of communicating. This version is also referred as the 
"near end" capable version. 


SS7IPGW 


FD-21 


R 


The TALI layer shall provide on a per-socket basis a string 
indicating what version of the TALI interface that the IP node is 
capable of communicating. This version is also referred as the 
"far end" capable version. 


SS7IPGW 


FD.22 


R 


The TALI layer shall provide on a per-socket basis a string 
indicating as to what version of the TALI interface has been 
negotiated between the SG (near end) and IP node (far end). 


SS7IPGW 



Table 19: TALI Requirement Table 

5. PERFORMANCE 

foSr'^^^Se 'r,1 Tr''^ ^J"^' ^ ^""^'^ ^^PP^° ^ '^'^ «°^ket polled for every point 

code? . The DOl could easily be overwhehned. TTie answer is to limit the number of audits processed As stated 
m requuement FD-8 audits will be discarded if the congestion threshold is exceeded. If the pSvHs dkcardS a 

30 seconds, it is assumed the IP device will only query at a similar rate. ^ 

6. RELIABILITY 

^ella nriZT.'tf'' "'"^"'^ P'^^^'^^S notifications to the IP-NE so it can direct traffic to the 

^1^1 w^^r . ' ' '"T""^"^ ^"'^ 'y'''"^ '^^^^^^^ ^P^^^ to the SG because of this 

stmcrro"^^^^^^^^ 
jfoSr^e^XT^^^^^ 

It should be noted that all non-query primitives received by the SS7IPGW card would be discarded Furthermore 
excessive queries wiU be discarded. Excessive queries can be eliminated if the IP node will only sendT^Zt o^ce 
the previous request has been acknowledged. This will allow a minimum of one query per socket to be pLcessed 

neS r^'f °° ^^""T" ' '^^ ^""^'^ ""''^ '° b^^'l'^^^t to multiple sockets. Ihe IP node will 

need to miplement a congestion abatement procedure such as the one documented in section 13 of [1 1]. 

To ensure that IP-NE gets the correct information about a PC, the last primitive sent by the SG will always provide 
^e correct mfonnation This is achieved by keeping each phase of priliiitive independent of each o&eT Sis 
fransmission of a PC UA primitive in response to a PDU to a prohibited PC wiU not have effect on eT^er 
transmission of broadcast or on query response primitive and so on. The down side of this solution is- the IP-NE 
IZrS. ?^ P™"^^^^ gi^g infomiation or the worse case, it might get a primitive with stale/wrong 

mformation followed by a pnmitive with coirect information. ^ e, f aic/ wrong 
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6.1 Primitive Duplication 

Duplicate primitives will be transmitted if the craftsperson has configured duplicate sockets to the same hosts. This 
is a user configurable condition that will not be prevented by this feature. However, there will be no duplicate 
response method TFP/TCP primitive transmissions due to the Gateway Layer and MTP3 both performing response 
method. 

6.2 Lost Messages 

There exists the possibility for an IP device to not receive response method notifications. Consider the network 
diagram in Figure 4. Suppose MGC 1, whose point code is 4-4-4, sends a MSU to 1-1-1 using the socket on DCM 
2. For some reason, a response method MSU is retumed but due to SLS problems, the response is sent to DCM 1. 
DCM 1 cannot send the response to MGC 1 because the socket is down. However, there is a socket to MGC 2 that 
also has a point code of 4-4-4. So DCM 1 will believe it has sent the appropriate notification to the originator of the 
MSU when it actually did not. 



4-4-4 




V ; 

Figure 4: Lost Response Method Network Diagram 



7. SERVICEABILITY 

This feature is designed to provide MTP status information to IP connected network elements. 

Several commands have been modified to assist the customer and customer service in using this feature. These 
changes are detailed in Section 4.7 and are summarized below: 

• SOCKSTATE provides the capability to determine if a socket is configured to transmit MTP primitives and 
what version of the TALI interface is being used 

• MSUCOUNT provides the measurement of primitives transmitted, received and discarded on a per link 
basis 

There is no impact to customers using the existing TALI LO interface. To gain benefit of this feature, the IP-NE 
must use the TALI 2.0 interface. 

There are two reasons primitives will be discarded instead of being transmitted: 

1 . socket not configured to transmit primitive 

2. socket not in established state 

The Broadcast Exception Indicator (BEI) of the ENT-DSTN command, which specifies whether the SG broadcasts 
network management message to adjacent signahng points, will essentially turn off primitive broadcasts. 



Title: IP7 Secure Gateway 2.0 MTP Primitives Feature Description 
Doc No.: Fd0027822 |PVCS#: 1.1 

Page 26 of 29 



8. LIMITATIONS 

One capability this feature provides is for an IP device to build up routing tables before sending traffic TTiis is 

atl? "^^.^^^t^rt f^^ture [10]. However, an important distinction is that traffic is not'stopped wWk route 
status information is being provided to the IP device. 

The following assumptions are made with respect to the IP node: 

• the IP node is responsible for abating congestion 

• the IP node is responsible for understanding cluster point codes 

• the IP node must not generate excessive audits (see section 5) 



9. APPENDIX A - PEER REVIEW CHECKLIST 



Item 



Was the template used and are all sections included (NA sections are so noted not 
deleted)? ' 



Do the version numbers in the change history, header and footer of this document match 
the version number in the document control system? 



Were the corre ct quorum members present or represented per the Pe er Review procedure? 
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Are all applicable PFS requirements documented in the PFS Compliance Matrix section? 



Compliance (Yes, No 
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document? 



Is there an explanation in the "Limitations" section of all FD requirements that were not 
fully compliant? , 
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Are there any changes to existing outputs or new error outputs that may impact the 

customer? If so, are they identified and appropriately documented in the user interface and 
serviceability sections? 
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Actions & Issues 

Modify TALI 2.0 TR to add User ID field for UP UA primitives. 



General Comments 

1) Remove left side of the footer completely. 

Specific Comments 

1) page 1 Change EAGLE to IP7 

2) page 1 Consider removing Secure Gateway fi-om title 

3) page 1 List all authors instead of just Tekelec 

4) page 13 Length in Table 9 wrong 

5) page 13 Show all fields in primitive in Table 9 

6) page 14 Remove first sentence 

7) page 14 Clarify duplicates in last paragraph 

8) page 16 Make subsections and clarify 3.4.3 

9) page 17 Clarify wording in bullets 4 and 6 

10) page 19 Length in Table 12 wrong 

1 1) page 19 Show all fields in primitive in Table 12 

12) page 25 GR-246-CORE not in reference section 

13) page 27 Remove first paragraph 
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